.NETのクラスライブラリ設計 改訂新版
2021年に発売された.NETのクラスライブラリの設計に関する書籍．
第1章
よく設計されたフレームワークは単純である．
クライアントファーストプログラミング
ミーティングのコストを見積もることができる．
参加者の人数 x 参加者の平均時給 x 時間 ( x 頻度 )
設計に不備がないと感じるのは，見落としをしていると考えるべき．
シナリオ駆動でAPIを設計するべきである．
テスト駆動開発のように，ユースケースから書いていく．
API仕様は機能仕様より先に書く．
シナリオを10個くらい列挙し，それらのシナリオを実装するコードサンプルを示すべきである．
APIを公開したことで，将来的に公開したい需要の高いAPIと衝突してしまうことがある．公開しない方がよいAPIがこの世に存在する．
複数のプログラミング言語をサポートするAPIは複数の言語でコードサンプルを示すべきである．
動的型付け言語でも書く．
ユーザビリティスタディを行っていく．
早期に実施するのが最適．
2.2.2 参入障壁低減の原則
一般的なシナリオで使用される型ほど浅い名前空間のところに置き，上級者向けのものほど深い名前空間にまとめてしまう．
StringBuilderはSystem名前空間にあった方がよい．
コンストラクタに単純なオーバーロードを実装する．
プリミティブ型で引数を受け付ける．
ユーザが複数のインスタンスを明示的に作成する必要があるようにはしない．
2.2.3 自己説明的なオブジェクトモデルの原則
単純なシナリオでは，フレームワークはドキュメントを必要とせずに使用可能でなければならない．
IntelliSense向けに最適化する．
テクニカルライターを早い段階で設計に参加させる．
2.2.3.4 一貫性
既存のフレームワークと一貫性をたもった設計にする．
2.2.3.5 抽象の制限
主流なシナリオで使用されるAPIでは抽象が多くなることを避ける．
2.2.4 レイヤー化されたアーキテクチャの原則
機能の豊富さや強力さを提供する低レベルAPIと，単純で便利な高レベルAPIに分解することができる．